Electronic billing and payment (EBP) is widely available today due to the proliferation of the Internet and ubiquity of consumer computing devices. However, EBP acceptance by consumers has generally been by early adopters. The remaining members of the potential consumer base are aware of EBP, but have not yet availed themselves of the advantages of electronic billing and payment. There are barriers that, if addressed, can substantially increase the number of both consumers making up the EBP consumer base and EBP transactions.
FIGS. 1A and 1B show current models of EBP services. FIG. 1A shows the Biller Direct model. FIG. 1B shows the Service Provider (SP) model. The Biller Direct model includes multiple electronic billers A′ through M′. Each of these electronic billers A′ through M′ maintains their own electronic billing enrollment and activation data, shown as databases 101 through 102. In the Biller Direct model enrollment and activation is a single process. A consumer 105 interacts with each of electronic billers A′ through M′ separately to begin receipt of electronic bills. Prior to enrollment and activation of electronic billing, each electronic biller A′ through M′ maintains information about each of their customers in databases 101 through 102. This is common information maintained by billers about customers. The consumer 105 must request to receive bills by providing enrollment and activation data, in addition to the information already maintained, to all electronic billers A′ through M′. Enrollment and activation data is provided via communications channels 106A through 106M. The consumer provided enrollment and activation data for electronic billers A′ through M′ is very similar, typically merely consumer identifying information such as the consumer's name, in addition to perhaps other consumer identifying information such as address, phone number, etc. Thus, the consumer 105 ends up providing the same or similar data to each of electronic billers A′ through M′.
The provided consumer identifying enrollment and activation data for electronic billing can include any or all of consumer name, phone number, billing address, and perhaps a service address, depending on the type of electronic biller. In addition, a consumer 105 may be required to provide an account number with each particular electronic biller from which electronic billing is being activated. Some electronic billers require an enrolling consumer to provide identity confirming information that is not typically publicly known, such as social security number (SSN) or mother's maiden name. Many electronic billers require the same identity confirming information. It will be apparent that in enrollment and activation via the Web the consumer 105 has to access Web sites hosted by each of these multiple electronic billers A′ through M′ to provide enrollment and activation data at every single electronic biller Web-site. Typically, the only different (unique) piece of information required by each electronic biller is the account number, because, as known, these differ by biller.
FIG. 1A also shows the consumer 105 enrolling for making on-line (electronic) payments to biller A′ through biller Z′. Enrollment is shown via communications channels 108A through 108Z. Enrollment for making electronic payments is separate from enrollment for electronic billing in the typical Biller Direct EBP system. Required consumer supplied enrollment data for electronic payments is, here again, similar in nature among various electronic billers (payees), and typically includes funding account information. Each of electronic billers A′ through Z′ stores enrollment data for on-line payments in separate data repositories, 110 through 111, than those in which enrollment data for electronic billing is stored, 101 through 102. Typically, the enrollment data for making electronic payments is not linked to or otherwise shared with the enrollment data for receiving electronic billing, as shown by the separate electronic billing data repositories 101 through 102 and electronic payments data repositories 110 through 111. It should be noted that not all electronic billers offer electronic payments, and that not all billers offering electronic payments offer electronic billing.
In a Biller Direct model there are multiple ways that electronic payments can be performed. In one, an electronic biller A′ through Z′ provides all the functionality for completing the payment. That is, an electronic biller presents a user interface for payment via a communications channel 108A through 108Z, captures enrollment data for payments from the consumer 105, warehouses payment requests in data repositories 110 through 111, processes the payment requests, and issues all debits, credits, and remittance advice associated with payment requests.
In another way that electronic payments can be performed, an electronic biller A′ through Z′ shares the functionality for completing payments. An electronic biller presents the user interface, but outsources the actual payment processing to a service provider, not shown in FIG. 1A. There are multiple variations as to whether the electronic biller or the service provider captures enrollment data for payments and whether the electronic biller or the service provider warehouses payment requests. In any event, a service provider processes the payment requests and issues all debits, credits, and remittance advice associated with the payment requests.
Yet another way that electronic payments can be performed, an electronic biller A′ through Z′ can completely outsource the payment functionality, including the user interface. This variation is much like the SP model of EBP services, to be discussed below. A service provider manages everything from the gathering of payment enrollment data through completion of a payment.
In enrollment for on-line payment, the consumer 105 typically provides, for each payee (billers A′ through Z′), customer name, customer address, phone number, and information identifying a funding account from which payment will be made. With some billers it is not necessary for a consumer to provide name, address, and account number information if that consumer is already enrolled for electronic billing. The consumer need only supply funding account information. This same information is required for payment to each payee. The different piece of information, among payees, as above, is the consumer's unique account number associated with each payee. In the Biller Direct model of FIG. 1A, the consumer 105 has to enter similar or the same data for every electronic biller, whether electronic bill receipt or on-line (electronic) payment is desired. Thus, existing EBP enrollment and activation processes are very redundant.
Accordingly, a need exists for an efficient enrollment and activation technique in the Biller Direct model of electronic billing and payment.
Typically a funding account is a demand deposit account (DDA) which can be debited via the Federal Reserve's Automated Clearinghouse (ACH). Deposit account identifying information required for electronic payment includes a financial institution routing number (RTN) and an account number (DDA). RTN and DDA information is found at the bottom of a consumer's check. Consumer 105 is required to either memorize this information, or have a checkbook available at the time the information is supplied to a payee. Not only must the consumer 105 have a check available when entering RTN/DDA information, if not memorized, he or she must have a bill from a biller available when supplying account numbers, if account numbers are not memorized. Some billers accept payment from other types of accounts, such as credit card accounts and money market accounts. Money market accounts are also debitable via the ACH. It is known that oftentimes consumers enter RTN/DDA information and other account numbers incorrectly. For example, digits are often transposed. While an account number with a biller typically has to only be entered once, RTN and DDA, or other funding account information, information has to be entered multiple times, once for each biller.
Accordingly, a need exists for an enrollment technique for electronic billing and payment which reduces incorrect entry of enrollment and activation data.
Prior to even beginning an enrollment process the consumer 105 is required to locate Web sites of every one of these electronic billers A′ through M′ and/or payees A′ through Z′, whether this is through a search Engine or a marketing message received by the consumer 105. Consumer 105 has to locate and access Web sites, determine if a particular biller offers the desired service (electronic billing and/or electronic payment), and then begin the enrollment process, which itself has deficiencies as discussed above. Thus, finding a particular biller and/or payee on the Web and determining if they offer electronic billing and/or electronic payment services takes time, effort, and initiative on the consumer's part.
Accordingly, a need exists for a technique to efficiently match consumers who desire electronic billing and/or electronic payment with billers who offer such services.
FIG. 1B shows an EBP model in which a service provider 120 is the primary connection for a consumer 115 to reach electronic billers and/or payees. This is known as a SP model. In the SP model enrollment and activation are separate processes. As shown in FIG. 1B, a consumer 115 communicates via communications channel 130 with a SP 120. The consumer 115 enrolls with SP 120, not individual electronic billers A through M. Shown from SP 120 are communications channels 142A through 142M to electronic billers A through M. Thus, one of the advantages for the consumer 115 in this model is that enrollment data is only entered once. Enrollment data is stored in enrollment database 135 by the SP 120. This core enrollment data includes the consumer's name and address and other key consumer identifying information. While the consumer 115 is only required to enter enrollment data once, the consumer 115 must enter activation data for electronic billing for each electronic biller. This activation data often includes part of, or even all of, the same data as required for enrollment.
Also shown in FIG. 1B is multiple instances of stored activation data 140A-140N. This reflects the fact that even though the consumer 115 has enrolled once with the SP 120, he or she is still required to activate receipt of electronic billing for each of electronic billers A through M separately. The consumer 115 has to enter activation data for each biller. Thus, for electronic biller A, consumer 115 is required to enter activation information such as social security number, mother's maiden name, etc. Further, consumer 115 has to continue to enter this information, or variations thereof, each time they activate a new e-Bill from a different electronic biller in this model. To begin activation, the SP 120 typically presents a list of all the billers for which the SP 120 presents bills. The consumer 115 selects those billers he or she wishes to activate. The service provider 120 then transmits an activation notice to each selected biller informing the biller to begin to provide bills to the SP 120 for presentment to the consumer 115.
Accordingly, a need exists for an efficient enrollment and activation technique in the SP model of electronic billing and payment.
In the SP model of EBP services the consumer 115 has the capability within one site to enroll for and review multiple electronic bills. This diagram also depicts a data store 150 associated with the SP 120 labeled “Other Subscriber Data”. This reflects the fact that consumer 115 can also access the SP 120 to pay billers other than electronic billers A through M, because this “Other Subscriber Data” includes payment data.
Different SPs offer one or more of at least three different payment models. A first is a ‘closed payee list—electronic biller’ model in which only electronic billers presenting electronic bills through a SP can be paid. That is, the only payments available are payments of received electronic bills. A second model is a ‘closed payee list—electronic biller and managed payee’ model in which electronic billers as well as payees with which the SP has a relationship can be paid. A third model is an ‘open payee list’ model. In an ‘open payee list’ model, consumers who enroll for EBP services can pay any payee.
Not all electronic billers that the consumer 115 would want to receive e-bills from offer electronic billing through SP 120. In such a case, the consumer 115 has to enroll with those electronic billers via a Biller Direct model to be able to receive those e-bills, or perhaps even via another SP. Thus, consumer 115 would still have multiple locations in which to enter redundant information.
Referring back again to the Biller Direct Model, as discussed above, consumers have to enroll in multiple places to make electronic payments and/or receive electronic bills. In addition to the problems discussed above, consumers have to remember which sites at which they have enrolled, as well as multiple site access code (consumer ID) and password combinations. Because of different site requirements a consumer may not be able to obtain a desired ID/password combination. Also, a desired ID/password combination may be unavailable because it is already in use by another consumer. So, yet another barrier to the making electronic payments and/or the receipt of electronic bills is that consumers have multiple Web sites they have to access to make payments as well as multiple Web sites to access to see bills and/or payment history. Each of these sites requires a consumer ID and password. A consumer must have available the correct ID/password combinations upon each visit to a Web site.
One of the solutions to the problem of multiple user IDs and passwords is found in the on-line retail market. However, the solution only applies to electronic payments, not electronic billing. Today there is known a third party payment service provider which supplies payment services which are accessed via a payment link that is found in multiple Web sites operated by disparate on-line retailers. That is, multiple unrelated retail Web sites each have a link to a single payment service provider Web site. A consumer has to only enroll once for this third party payment service. The on-line retailers provide the link for the consumer to access this payment capability. Once the link is activated, the consumer's browser then is redirected to a third party hosted Web site in order to enter payment information.
In FIG. 2 are shown blocks 205A-205N, each representing one of multiple Web sites a consumer could go to make payments using this third party payment service. Shown are an auction Web site 205A, a retailer A Web site 205B, retailer B Web site 205C, retailer Web site C 205D, and a Web site of the third party payment service provider itself 205N. At each one of these Web sites 205A-205N there is a payment link 210A-210N that represents the third party payment provider. Once activated by a consumer, the consumer's browser is redirected to a Web site for payment 201 hosted by that third party provider and branded as the third party provider. Of course, with link 210N a consumer is already visiting a web site of the third party payment provider. The payment Web site 201 is not branded based on the site from which the consumer may be making a purchase, nor is any of links 210A, 210B, 210C, or 210D branded based upon the Web site at which each respective link is found. Once the consumer has entered payment information at the third party payment service provider, then it is up to the third party payment service provider to feed information associated with the payment back to a seller from which a purchase was made.
The third party payment service provider does provide a single view of all of transactions for a given consumer. The consumer can go directly to the third party payment service provider in order to see all of his or her payment history as well as make payments. This provides the same user experience no matter where the consumer is activating a payment link 210A-210N. However, it should be noted that the third party payment service provider only offers a closed payee list. That is, only certain payees can be paid, those having a business relationship with the third party payment service provider. This third party payment service has a one-time enrollment feature and the consumer uses the same user ID and password no matter the Web site from which the payment link 210A-210N is activated.
The third party payment service provider technique of FIG. 2 works well in the retail environment, however it does not work well for companies who feel like their brand is very important with their customers and would like a user experience to be the same whether the consumer is viewing an e-bill at the company's site, or doing anything else from the company's site, including paying a bill or making a purchase. In order to have a branded environment today, there are isolated silos of EBP activity such that a consumer has to go to multiple sites and have multiple user names and passwords in order for billers to have branded environments and otherwise control the user experience, as discussed above.
Other models of EBP functionality exist in the SP model context which address consumer desires to view electronic bills at a single location. One is known as ‘scrape-and-pay’. Here a consumer still has to locate each electronic biller Website and set up a unique relationship with each electronic biller, including establishing ID/password combinations. The consumer provides each biller ID/password combination to a ‘scrape-and-pay’ service. The service, based upon the consumer-provided ID/password combination, gathers billing information from each electronic biller Web site and then presents this information to the consumer. In this approach, the consumer still must establish relationships with multiple electronic billers, and electronic billers have no control over the final presentation of electronic bills to consumers.
Another model of EBP functionality in the SP context also allows a consumer to view bills electronically and is known as ‘scan-and-pay’. Here a consumer issues a directive to a biller to have his or her paper bills delivered to a ‘scan-and-pay’ service. The ‘scan-and-pay’ service, upon receipt of a redirected paper bill, merely digitizes at least part of the received paper bill and presents it electronically to the consumer. While this service does make paper bills electronically available, there are several problems with this service. First, a consumer must actively change his or her billing address to the address of the ‘scan-and-pay’ service provider. Thus, the consumer must take actions with each biller to receive electronic bills through a ‘scan-and-pay’ service. Also, as a result of the redirection of the paper bill, the biller loses a line of communication to the consumer. Thus, often times important information, such as changes to terms and conditions, are not communicated to the consumer because a ‘scan-and-pay’ service does not typically digitize the entire contents of the paper bill, including inserts. The redirection of the paper bill also means that the biller loses control of the presentment experience, albeit a paper presentment. It should be noted that the problems of loss of control of the presentment experience as well as loss of a line of communication are also present in ‘scan-and-pay’ services. Also a problem with paper bills being redirected, replacement credit cards have been directed to a scan ‘scan-and-pay’ service instead of the consumer, as often a biller does not know that an address to which paper bills have been redirected is not an address of a consumer.
In view of the above, a tension exists between consumer desires to view and pay bills available at multiple different sites from multiple different billers and make purchases at multiple different sites using the same user ID and password and via a one time enrollment process, and billers' desires to control the branding and user experience of the presentment and payment of bills and as well as Web site purchases.
As such, a need exists for a technique of EBP services in which a consumer can view electronic bills of various billers and make electronic payments to various payees utilizing a single user ID/password combination that allows billers and/or payees to control the branding and the user experience.
FIG. 3 depicts a precursor situation to enrollment for EBP services. In FIG. 3 is shown is a consumer 301 who is interacting with their e-mail inbox 305. The consumer 301 may be interested in paying bills on-line and/or receiving bills on-line, but he or she is not quite sure how to achieve this. Also in FIG. 3 is an actual physical mail box 315. The consumer 301 can receive a paper bill in their physical mail box 315 and they can pay that bill via conventional avenues, i.e. by check mailed to a biller. Perhaps consumer 301 has received an offer, perhaps within a paper bill, to participate in e-billing. Accordingly, an e-bill offer 320 is shown being delivered via the traditional mail box 315. This offer could come from either electronic biller A or electronic biller B. Thus, an electronic biller is sending out a paper bill to the consumer 301, and within the paper bill is an e-bill offer 320 to begin to receive that same paper bill in an electronic fashion. It is an offer to receive the bill on-line, and perhaps to even pay it on-line. Such offers are sent to all customers of a biller sending the offers. They are not targeted to those customers likely to act on them.
The consumer 301 has to take that offer and do something with it. He or she has to access the Web, locate the biller, and enroll. As also depicted, the consumer 301 may currently be enrolled with some sort of payment service to make electronic payments. Shown is SP 330 for making electronic payments. Thus, in this example, the consumer 301 is actually making electronic payments. As shown, the SP 330 pays electronic biller B on behalf of the consumer 301, but the consumer 301 has not enrolled for any e-bill service. While the consumer 301 may be interested in viewing and paying bills on-line, there is currently no technique to easily sign up for electronic billing, even in cases where the consumer makes electronic payments of received paper bills. The consumer 301 still must visit one or more Websites and enroll for and activate electronic billing, as discussed above.
Accordingly, a need exists for an EBP service which facilitates consumer enrollment.
FIG. 4 depicts yet another problem in enrollment for electronic billing. At the time of enrollment in today's systems, a consumer has to include payment account information, even though only e-billing services may be desired. Received enrollment information, including payment account information, is typically processed for identity verification. This processing often includes leveraging commercial identity verification services, such as Equifax. This processing also includes risk processing that relates to payments, not billing. Some customers fail this risk processing even though they only desire electronic billing. To support the identity verification and risk processing consumers are required to enter many fields of data. The required data is personal data that many consumers perceive as being extra sensitive. Examples of this data include drivers license information, mortgage, and other loan information. Additionally, this is a time consuming process.
FIG. 4 depicts Web sites 401A-401N associated with Biller A, Biller B, Biller C, and a SP. Each of these sites offers electronic billing as well as electronic payments. A consumer independently has to enroll at each of these sites, as discussed above. Even though a consumer may only wish to receive e-bills, that consumer would have to fully enroll, in which supplemental information for risk management in addition to identity verification must be provided. Thus, the enrollment process ties together information required to receive e-bills with bank account information required to pay bills.
In a SP model, once a consumer enrolls with a SP from site 401N the consumer has to activate individual e-bills 405A-405N, as discussed above. At the time of activation the consumer must enter specific information that billers may require. As also discussed above, a consumer could end up having to supply the same information multiple times in order to activate different bills.
In summary, from a consumer perspective, the consumer has to give the same information out four different times to enroll with Billers A through C and the SP. The consumer goes to the Biller Direct Web site 401A for biller A, and enters in their name, address, e-mail address, or other identifying information. When the consumer goes to the Biller B Biller Direct Web site 401B or the Biller C Biller Direct Web site 401C, as well as the SP Web site 401N, the consumer has to re-key much of the exact same data multiple times. This is also shown in FIG. 1A where biller A′ and M′ have their own databases storing enrollment data that is not leveraged anywhere else and in FIG. 1B with the siloed activation data.
As introduced above, EBP systems have achieved significant adoption in the marketplace, but have not yet lived up to their full potential. Getting consumers to enroll in EBP services is one hurdle, followed by getting the enrolled consumer to actually use the EBP system to pay bills and make other payments. Due to the effort required to set up payees, including billers, some enrolled consumers never activate a biller or payee and are eventually purged from a SP's customer base.
As shown in FIG. 5, current generation EBP systems require the consumer to manually enter payee information in order to set up and activate each payee for electronic payments. This includes entering biller (payee) name 501, payment account information 505, remittance center address 507, phone number 509, as well as other information. Entering this data for multiple payees usually requires a significant amount of time and effort on the part of a consumer. Additionally, most consumers need to have their paper bill available as a reference during payee setup, as introduced above. It has been the experience of the assignee of the present application that the effort required to set up payees is a major reason why enrolled consumers never become active users of EBP systems.
While an individual consumer may need to pay bills or make payments to only a small number of payees, these payees typically are already associated with or otherwise known to a SP. For example, a consumer may choose to set up Ameritech as a payee, yet a SP may have thousands of customers who have entered Ameritech as a payee. As a result, it is likely that the SP may already store some of the information required to set up Ameritech as a payee of this consumer. This is especially true for billers that have electronic (e-bill) connections to the SP.
Some EBP systems already provide consumers with a “pick list” of billers to choose from in payee set up, as well as for biller activation. However, this approach does not fully exploit various possibilities for providing lists tailored for individual consumers or for identifying specific billers as candidate billers payees. This approach also does not utilize techniques to provide assistance and help automate the payee set up process.
Accordingly, a need exists for a technique for making it easier and faster for consumers to set up payees and/or billers.
A “Web service” is a network accessible interface to application functionality built using standard Internet technologies. Note that the phrase ‘standard Internet technologies’ is what makes Web services interesting. Computer users have been accessing application functionality over a network for a long time. However, up until now, the various communications protocols used in accessing application functionality were almost exclusively proprietary and unique in nature. Web services defines a common infrastructure to be used by all network-based applications and the clients that use them.
A collection of software and tools that enable developers to create, deploy, and access Web services has been proposed. One such proposal has been made by Microsoft™. It is important to understand that even though Microsoft™ software suite for enabling Web services, known as the .NET platform, is perhaps the most well known, it is by no means the only way to build or use Web services.
A large component of Microsoft's™ .NET proposal is to offer to consumers (presumably for a fee) a suite of commonly used Web services. This bundle of remotely accessible application functionality, dubbed Microsoft™.NET My Services, is expected to be publicly available sometime in 2002. Though the exact pricing, business model, and functionality of .NET My Services has not yet been made public, some proposed services include: .NET Profile, which associates a name and other personal profile information with a subscriber; .NET Contacts, which stores electronic relationships/address book for a subscriber; .NET Alerts, which provides subscriber alert subscription, management, and routing functionality; .NET Calendar, which provides time and task management; .NET Wallet, which provides storage for payment instruments as well as perhaps transaction records; and .NET Passport, which is an authentication service.
.NET Passport allows participating subscribers to create one sign-in name and password for use across participating .NET Passport sites. Additionally, subscribers can save time and avoid repetitive data entry by storing basic demographic information that can be shared with .NET Passport sites. When a subscriber signs in to a participating .NET Passport site, .NET Passport sends the subscriber's identifying information such as ZIP Code, country/region, and city information to the site upon request, or, alternatively the .NET data repository can be accessed by participants in the Web service. Subscribers can also choose to provide their nickname, e-mail address, age, gender, and language preference.
Clearly, universal adoption of .NET Passport would go a long way towards simplifying a consumer's Web experience by alleviating a great deal of data entry and removing the need to memorize a different set of authentication credentials (i.e. ID and password) for each Web site they visit.
.NET Alerts can be utilized in a number of interesting and divergent scenarios, including appointment and special events reminders, monthly bill or statement availability online notification, notification of excessive stock price movement; traffic alerts; notification of a bank account being overdrawn; or notification of a magazine article being available based on previously entered keywords. It should be noted that as of yet no specific proposals for utilizing .NET Alerts for online notification of electronic billing availability is known. At best, it is merely envisioned that .NET Alerts could support notification of a newly issued bill being available to a subscriber already receiving electronic bills from a biller issuing the newly available monthly bill.
.NET Alerts is envisioned to allow businesses to notify consumers of important events that the consumer can then, optionally, act upon. An alert is a short instant message that .NET Alerts providers can send to subscribers who opt to receive them. The alert is routed based on the subscriber's delivery preferences and can be delivered directly to desktops, mobile devices, and any e-mail address. As an example, a subscriber will commonly opt to have alerts routed to their Windows Messenger client when online and to an e-mail address when offline. Routing to pagers or to a telephone number is envisioned.
Microsoft™ appears to envision .NET Alerts as a strictly “opt-in” service in which consumers subscribe only to alerts that they want and can unsubscribe at any time. This would avoid spam in .NET Alerts, which is spurious, unwanted, or undesired received communications. It is emphasized that subscribers will only receive the notifications that they want. .NET Alerts are envisioned to be free of spam.
.NET Wallet, yet another Web services data repository, is envisioned to provide a repository for a subscriber's various payment vehicles (e.g. credit card numbers, bank account information, coupons). Much like .NET Passport, the wallet service relieves the subscriber's of much repetitive (and error-prone) data entry.
It does not appear at this time that Microsoft™ intends to provide payment processing functionality. Rather, it seems the intent is that merchants will query the .NET Wallet service for payment information such as a credit card number and it will then be up to the merchant (or perhaps a third-party) to actually ensure that a transaction is executed. Also, the current incarnation of .NET Passport Wallet (a precursor to .NET Wallet) does not capture bank account (RTN/DDA) information. Currently, it is exclusively credit card-based. Thus, .NET Wallet is merely a storage place for financial information, no substantial payment functionality is included.
Accordingly, a need exists for an EBP service which leverages Web services to support the entire EBP experience, including payment processing functionality, including payments based upon and made from subscriber's bank accounts, electronic bill location functionality, and electronic bill delivery functionality.